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(57) Abstract 

A system with a network interconnecting a server and a 
plurality of user stations. The server stores a plurality of user 
applications for downloading to user stations and further stores 
access permissions for the applications for each user. When a user 
attempts to log onto the system, the server uses the user's log-on 
identifier to build a list of applications for which the user has access 
permission. The server downloads to the station a list of applications 
to which the user has access permission. The user station uses 
the list to build a folder containing only the applications from the 
list to which the user has access permission. The system further 
verifies from the list that the user has access to applications that 
are represented by objects that the user may have added to his or 
her desktop at an earlier time. For each user desktop preference 
specified by the user at an earlier time that corresponds to a use? 
application, the access permission for the user to the user application 
is checked from the list, and, if the application is not included on 
the list, the desktop object representing the application is removed 
from the desktop. 
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CLIENT - SERVER SYSTEM FOR MAINTAINING A USER DESKTOP 
CONSISTENT WITH SERVER APPLICATION USER ACCESS PERMISSIONS 

The invention relates generally to the fields of personal computing 
and networking. Specifically, it relates to the new and evolving field of 
network computing, in which desktop computer users use a personal 
computer, possibly diskless, connected to a network such as a corporate 
intranet, the Internet, or to an network or Internet Service Provider 
(ISP) to gain access to applications which are then executed on the 
desktop computer. More specifically, the invention relates to 
server-based storage of software preferences (configuration data) for 
software retrieved from a server and executing at the desktop computer. 

The field of network computers is presently in its infancy. 
However, it is expected to evolve rapidly, especially in the corporate 
environment, for a number of reasons. The expectation is that as 
companies and possibly individual users reach hardware and software 
upgrade points, it will be more efficient and less expensive to move to 
this new field, rather than upgrade in the traditional way with disk 
equipped computers and locally stored and administered software 
applications. For example, in the corporate environment-., a vser can bt: 
connected to a corporate intranst, using, for example, -i P/IP and ir.vTP 

protocols of the Internet, and download software applications as they are 
needed directly from a network server to the desktop computer. An 
application is executed on the desktop in the traditional manner by the 
user to perform useful work. An advantage of this configuration is that 
network computers are substantially less expensive than traditional disk 
equipped computers. It might also cost less to purchase the required 
number of software licenses for users, rather than purchase individual 
copies of software for each user. Certainly, the software administration 
problems that attend large numbers of corporate users will be 
substantially reduced. At the present time, each user of a disk equipped 
computer or workstation often is effectively his or her own system 
administrator, a role that often consumes excessive resources due to lack 
of expertise. It is expected to be o great advantage to eliminate this 
problem by effectively offloading the problem to a small number of server 
administration experts, rather than having many users struggle with the 
problems of software installation, upgrades and computer administration. 

As mentioned above, this vision of the future of personal computing 
is presently in its infancy. As a result, there are presently many 
problems and deficiencies with existing systems. 
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Typically, in network computer systems, an administrator creates 
user profiles that are stored on a network server. The profiles may 
contain different types of information, such as user desktop preferences 
and user permissions for access to different software applications that 
5 might reside on the server, when a user logs onto the system, the user 

identifies him or herself to the server, the server locates the profile ■ 
for the user and transmits it to the user computer where it is used to 
configure the computer and generate a desktop. The desktop might include 
a number of icons representing applications to which the user presumably 
10 has access. The profile likely also contains other attributes of the 

computer and desktop, such as for example, the background colour of the 
desktop, or character fonts and point sizes used on the desktop, or data 
file search paths, etc. that are unique to the user. The profiles may be 
user modifiable or non-modifiable. 



15 



20 



In an environment in which users can modify their own profiles, a 
modified profile is uploaded back to the server at log-off time, where it 
is stored for retrieval the next time the user logs -on. In some prior art 
systems, to the best of our knowledge, the users can generate on their 
desktops any configuration of application icons they wish, whether or not 
they exist on the server, and whether or not a user actually has access 
permission to an application on the server. The Lotns workplace !>eskton 
(previously called Kona Desktop) system is an e; ■ : y.~ of this type of 
operation. in other system:, the server presents a list to the user of 
25 all applications that the server has, from which the user can pick. in 

this case, there is no guarantee that the user actually has access 
permission to an application that is selected from the list for inclusion 
on the desktop. The Sun Hot Java Views system is an example of this type 
of system. in other words, the prior art systems do not correlate between 
30 what the user can configure for the set of desktop application icons and 

applications to which the user actually has permission access. In such a 
case, when the user clicks on a icon to execute an application, an error 
message may occur (such as an unauthorized access message) if access 
permission is not present, or in a worse case, the user's computer may 
35 crash. 

Another limitation with existing art is that e flat data structure 
is used to model users, user groups, terminals and groups of terminals. 
Modeled after a common scheme for managing user access to computer 

40 resources, known network computer implementations (e.g., lotus 

Administration, Facility for Desktops, Microsoft windows NT Profiles and 
Policies, and Sun Hot Java views) implement a flat '.groups' structure on 
the server for managing software preferences (or attributes) in various 
contexts, A 'context', as used here, refers to an individual user, user 

45 group, terminal, or terminal ^roup. Any -grouping structure for 
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managing software preferences on the server allows an administrator to 
define preference attributes for different groups of users as well as for 
individual users. However, flat systems are inflexible in many 
environments, especially in environments having large numbers of users. 
5 It is desirable to provide an administrative tool supporting the 

organization of preference information into a hierarchical structure. 

Another limitation with existing systems is that they are limited in 
the ways that administrators and users have to perform user configuration 

10 of workstation desktops. For example, administrators are presently 

required to configure user preferences using configuration programs that 
are separate from, but associated with, a user application. It is 
desirable to allow vendors to provide only a single application. To 
require only an end user application from a vendor necessitates that the 

15 central management facility be able to execute the end user application in 

a context of a user or user group. The prior art does not allow this 
administrative flexibility of operation. In other words, in the prior 
art, to the best of our knowledge, an administrator does not have the 
ability to run a user application in the context of a user to set 

20 preferences for that user and application. Further, in the art, an 

administrator cannot run a user application tc set preferences in the 
context of a grc-jp of users. 

Still another limitation in the prior art known to the inventors is 

25 the manner in which the prior art partitions server permanent storage 

space to guarantee that a unique space is reserved for storing user 
preferences related to the different applications on the server. To the 
knowledge of the inventors, the problem of preventing collisions in the 
storage of preference information for different applications in 

30 object-oriented systems, in which an object can be queried for its fully 

qualified class name which uniquely identifies and differentiates it from 
other classes, is solved by having a first central authority assign a 
unique designation that applies to a vendor and by then having a second 
authority at the vendor assign a second designation relative to the first 

35 designation for each vendor application. For example, vendor A might be 

assignee the designation vender A by the first authority and that 
designation is guaranteed to be unique within the architecture for which 
the first authority is acting. The second authority at vendor A then 
assigns the second designation for each of its applications within that 

4 0 architecture. For example, one of vendor A's applications might be 

designated— vendor A. Appl ; another might be designated vendorA . App2 . The 
art maps the unique designation for each application in a system to a 
location in permanent storage of the system to guarantee that preference 
data for the different applications do not collide in storage. An 

45 application, when running, informs the network computer server of its 
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unique storage location and it is the responsibility of the server tn 
partition an area at the starting location according to Tco^lZ s 
user aroup, terminal ^ +^ ' 9 v ° a context -(user, 

. up, terminal or terminal group) for storing preference 
information so as not to mii^. ,,, . , „ €nce 
rtiff™,, . collide with preference information in a 

different context moa-r-i,, . A " 01 

v.wiit«xL. Clearly, this manner of administering e#.^ 
awkward and undesirable it i« • wi aQI ^stering storage space is 

aDie " xt xs desirable to Revise a method <-« 

e arore mentioned ob-j ect - oripnt*>r3 anri ij 

resorting to the reauirpm^, ^ u • or ^nted applications, without 

„ ujjc requirement of havina central s „fw: • 

into an application. location information 

Still another limitation in the art lies in the lack of anv 
provision to migrate existing applications and hardware into \T 
environment of the central i„ ms ^ = ^ are lnto the n ew 

e centrally managed network computing world wlt-v,™,- 

hardwire 9 £ ™ ~« - ^ 

r inf0 ti:r:„ e :;r;-:: ti ;:™ ^Tr^rrr 

located on a server Th^ 1-0™^=^ • specific format 

configuration fi" ^! " pr ° gre ™ ed to b~ to access its 

file Lm' no server ^V*™™ 1 3 to accsss the 

oerver. - rilt2 unique ider.r.ifier is o-ri- M 

that to „ hich the ter „ lnaJ Js ^ t h«« a «er.„t fro „ 

" " *" c °""S»'«'o» £11. ln the way {or „ Mch d esi 9 „ea 
" Pr °"*»' ■>•=.»» there are sl)ch e, isti „ 9 devices 

oo„ i9 „>„ 9 S o £ t».re within „ .a.i»i s tr.tio» f.cnit/£ coLZre 
preference information f or v.rioos users s»a „ser oroups 1^"'- , 
and terminal ermine t-v^ . . . s^oups, and terminals 

who 1. runniest, eel "w I T 5TOUP ' °" 

r^:rr— 
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According to one aspect, the invention provides, in a network system 
comprising a network interconnecting a server and a plurality of user 
stations, a method of managing desktops on the user stations from the 
server, wherein the server stores a plurality of user applications for 
5 downloading to user stations, and further stores access permissions for 

the applications for each user, said method comprising steps of: receiving 
at the server a log -on request including a user identifier from a user 
station; using the identifier to build a list of applications for which 
the user has access permission; downloading to the station the list of 
10 applications for which the user has access permissions; and displaying on 
a portion of the desktop objects corresponding to each application in the 
list, said objects when selected by the user being operative to request a 
download of the corresponding application to the user station. 

15 According to a second aspect, the invention provides, in a network 

system comprising a network interconnecting a server and a plurality of 
user stations, an apparatus for managing desktops on the user stations 
from the- server, said apparatus comprising: means for receiving at the 
server a log-on request including a user identifier from a user station; 

20 means for using the identifier to build a list of applications for which 

the user has access permission; means for downloading to the station the 
list of applications for which Lne user has access permissions; ar,o moans 
for displaying on a portion of the desktop objects corresponding to each 
application in the list, said objects when selected by the user being 

25 operative to request a download of the corresponding application to the 

user station. 

According to a third aspect, the invention provides a computer 
program product stored in a computer readable storage medium for, when run 

3 0 on a computer, carrying out in a network system comprising a network 

interconnecting a server and a plurality of user stations, a method of 
managing desktops on the user stations from the server, wherein the server 
stores a plurality of user applications for downloading to user stations, 
and further stores access permissions for the applications for each user, 

35 said method comprising steps of: receiving at the server a log-on request 

including a user identifier from a user station; using the identifier to 
build a list of applications for which the user has access permission; 
downloading to the station the list of applications for which the user has 
access permissions; and displaying on a portion of the desktop objects 

40 corresponding to each application in the list, said objects when selectee 
by the user being operative to request a download of the corresponding 
application to the user station. 

The system described herein provides a common repository for 
45 configuration information for users and applets in a client - server 
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environment. This is referred to as client profile manaoement The 
system allows users to roam, that is. to log-in from any computer in the 
system at any tame and have it configured automatically at run time 
according to the preferences stored for the user at the server The 
preferred embodiment is a Java (Java is a Trademark of Sun. Inc.) based 
system and the client computers use a web browser interface arranged to 
execute Java applications. Thus, in the preferred embodiment , user 
applets and the desktop applet are assumed -to be Java applets. However 
it as not intended to limit the invention to a Java environment 
Preferences for the locally stored applications might be stored locally in 
the traditional manner, while preferences for the server-based applets 
maght be handled in the way described herein. 

The invention solves the problem whereby a user is able to configure 
has or her desktop so as presumably to be able to access an application on 
the server when, in fact, the user does not have system permission to 
access the application, when the user logs onto the system, the user 
identifies him or herself to the server by means of a system identifier 
and a password. The server uses this information to built dynamically a 
last of applications to which the user has access permission. That list 
is transmitted to the users station. The application list is th~n n se d to 
Huild a portion of the ne.-.ktop. prftfei-bly a a***tap folder. 0 y 
applications to which the user has access permission. Preicv-,, > 
folder is composed ol a number of application icons each of which' 
correspond to a different application and which may be selected by the 
user to launch the associated application. Associated with each 
application in the list are parameters necessary for the user to execute 
the associated application. For example, one such parameter might be the 
URL on the server used to invoke the application. Nothing prevents a 
user from modifying the desktop. For example, after the desktop is built 
the user generally can add other application icons to the desktop, even 
though they would not be accessible to the user. A more common case might 
be where the user copies an application icon that is dynamically generated 
from the list from the generated folder to another part of the desktop and 
35 tnen logs off. when the user logs off. or otherwise saves his or her 

preferences for the desktop via any method the system miaht provide, the 
copaed icon is saved to the server and becomes pert of the preference* 
configured for the user. when the user later logs onto the system the 
copied icon is reproduced on the desktop, not as part of the automatically 
generated list of accessible applications, but just as part of the 
individual preferences set by the user. Thus, the user can still wind up 
wath applications configured on the desktop to whioh the user doe* not 
have access. A related feature of the invention prevents this occurrence 
from happening by also testing each application access preference set by 
the user against the application permissions present on the server. if a 
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user has included an application object on the desktop to which he or she 
does not have access permission, then the object is automatically excluded 
from the desktop object that is built by the server at log on time. 

5 In a preferred embodiment comprising a system with a network 

interconnecting a server and a plurality of user stations, the server 
stores a plurality of user applications for downloading to user stations 
and further stores access permissions for the applications for each user, 
when a user attempts to log onto the system from a user station, the 

10 server receives a user log-on identifier from the user. The server uses 
the identifier to build a list of applications for which the user has 
access permission. A desktop object is then downloaded to the user 
station to control the interface between the user and the user's station. 
The server also downloads to the station a list of applications to which 

15 the user has access permission. The user station uses the list to build a 

folder containing only the applications from the list to which the user 
has access permission. The system further verifies that the user has 
access to applications that are represented by icons that the user may 
have added to his or her desktop at an earlier time. For each user 

20 desktop preference specified by the user at an earlier time that 

corresponds to a user application, the access permission for the user to 
the user application is checked rrom the lis;:, and, if the application is 
not included on the list, the desktop object representing the application 
is removed from the desktop. 

25 

Fig. 1 shows an illustrative network and user stations, including an 
administrator's station, in which the invention might be practised; 

Fig. 2 shows an illustrative block diagram form of the 
30 administrator's station in communication with a server, and components of 

the administrator's station and the server for providing the central 
profile management and preference administration; 

Fig. 3 shows one illustrative hierarchical organization of user 
35 groups and users of e system. The illustrative hierarchical organization 

might also contain individual terminals and terminal croups; howevei , 
these are omitted for simplicity; 

Fig. 4 shows one illustrative listing of individual users and the 
40 group priority order that is used to determine a set of preferences from 
the hierarchical organization of Fig. 3 that apply to a user and a 
specific application executed by the user;. 

Fig. 5 shows a more detailed view of the administrator's station and 
4 5 server of Fig. 2; 
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Fig. 6 shows an illustrative view of the software objects at a 
user's terminal, including a user application and the API between the 
application and other components, that cooperate to establish the user 
preferences during execution of the application as the user's terminal ; 

Figs. 7 through 8 show illustrative operations at both a user's 
terminal and a server for user log-on and initially establishing the 
user's desktop, including desktop preferences, at the user terminal; 



Figs. 9 through 11 show illustrative operations at both an 
administrator's terminal and a server for administrator user log -on. 
establishment of the administrator's desktop, and. by way of example, the 
selection of an application and a context -for configuration; the example 
also illustrates a context change during configuration the user's -desktop 
15 and the resulting operations; and 

Figs. 12 through 24 show a variety of actual administrator screen 
snapshots in various phases of application administration, including 
building of 'a hierarchy of which Fig. 3 is a representation of an 
example of, the creation and deletion of users, etc. the establishment of 
application preferences for applications, and content changes during 
preference »rss-*blishment . 



The system described herein provides a common repository for 
configuration information for all users and applets in a client -server 
environment. This is referred to as client profile management. The 
system allows users to roam, that is. to log- in from any computer in the 
system at any time and have it configured automatically at run time 
according to the preferences stored at the server. The preferred 
embodiment is a Oava (Java is a Trademark of Sun. Inc.) based system and 
the client computers use a web browser interface arranged to execute Oava 
programs . 

The terms 'applet- and -servlet' are established terms in the Java 
35 programming language art and will be used herein, since the terms have 

meaning to those skilled in this art. 'Applet' refers to an independent 
software module that runs within a Oava enabled web browser. Servlet 
refers to a software module that resides on a Java enabled web server. it 
is to be understood that the use of the terms 'applet' and '-servlet' 
herein is not intended to limit the invention in any way. For 
clarification, the phrase 'configuration applet' is used herein to refcer 
to a software module used to configure preferences for an end user 
software application such as a word processor, a database manager, -etc 
Since software applications are also 'applets' in the Java environment 



BNSDOCID: <WO P9S7B63A1J_> 



WO 99/57863 PCT/GB98/03866 



the phrase 'user applet' or just 'applet' .is used herein to refer to an 
end user application. ■ 

In the preferred embodiment , user applets and the desktop applet 
5 are assumed to be Java applets. However, it is understood that the 

invention is not limited to a Java environment. The invention can be 
used in any client-server system. For example, if desired, the system 
could be designed to use proprietary communication protocols and 
applications written and compiled in any desired programming language. 

10 Further, even in the preferred Java based environment, disk-based 

computers might access some applications locally, and other applets from 
the server. Preferences for the locally stored applications might be 
stored locally in the traditional manner, while preferences for the 
server-based applets might be handled in the way described herein. 

15 Preferably, however, preferences for locally stored applications are 

stored on the server using the Profile Management Properties API in 
addition to the preferences for server based applets described herein. 

A simple Application Program Interface (API) allows applets written 
20 to the API to easily store and retrieve preference data when the applet is 

executed" by a uaor or administrator. Applet permissions and user 
pie Terences c an b & defined b ed on a r c up embe rships and i n d i v i 0. u c- .■. 
identity. 

25 Client profile management includes the following services: 

Log -on support - mapping to a user profile; 

User support - the administrative ability to create user identifications 
30 and provide services and preferences directly to users; 

User groups support - the administrative ability to create hierarchical 
groups of users and provide services and preferences based on group 
memberships ; 



3^ 



40 



User applet context transparency - automatic determination of the context 
of user applet execution. That is, the determination of the user and/or 
group profiles that apply to a user applet execution and the automatic 
establishment of the profile environment; 

User applet preferences repository - context-sensitive server storage for 
user applet configuration data; 
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Dynamic user applet preference 4t^^,-«. 

^ w ^ lcI «ences inheritance - hierarchirai ^- 

default group privileaes and oerT ' / «» -erride 

for individual users" " ^ additional a — Privileges 

Profile management provides a framework through which these tasks 
are performed, some tasks are supported bv 

p ° oy Profile management direen« 
e.g. user/group management, applet lists r™..« • ! directly, 

ww -lists, context switching, preference 
inheritance, etc.. while configuration services so^ifi^ ^terence 
are usually supported by separate rmif specific to user applets 

Dy se P a rate configuration applets invoked hv * 
system administrator within the client profile management environment 
Some end user applets might provide the configuration capahtl Im part 
of the end user applet, if this is the case, the administrator can run 
the end user applet (as opposed to a separate configuration applet" Z the 
context of individual users and groups to set the configuration 
preferences for those users and groups. 

rig i shews cv-.- hiuh if-ve 1 ■ 

. . y ic "" v or «n munced envirr^ent for 

ZZ:T'' J iRV — * 100 is provided for interceding 8 

; 3lUy ° f US6r StBtions ' - desktop personal computers loT mobile 

laptop computers 10,, workstations 106 (e.g., RISC -computers) an 
aommistra tor's station 108 and a server 110 in one Lk^ - 

100 might be a local area network In L ' °" lm6nt ' netW ° rk 

. . , networx. m another embodiment, network lOfl 

might include wide area networks <w „ K 100 

ieo neiworxing for entities such as corporations «-h«t 
have geographically displaced site- that — • , operations that 

30 system. There is no in Lt o 1 are still ^eluded within the 

intent to limit the environment in whi-ch the 
invention might be practised; indeed, a network of any type that 
interconnects many types of stations is envisioned. 

- oper-tLo'ln' 1 " 61 dl59raJn ° f Pr ° fiie "»»•••"-»' administrative 

operating environment is shown in Fic >^ ~ - > 

, - ajJe client and server -communicate via e 

network represented as 203. The particular example of Pig. 2 s ^ s , that 
^ the client computer is a system administrator's computer. 

Profile manager 206 on the client side allows the administrator to 
configure user applet preferences at both user a,d group leve 11 
aom nistrator can create new users and group hierarchies, add users! 

.5 Ind WidlY^ 5 ' SPeCify ************ ^or. -ea^up and for 

mcividual users. *nd the administrator can configure applets in the 
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context of an individual user or a group. The administrator can add, 
delete and reset passwords for users. Profile management support is 
transparent to the general user. The administrator can invoke the profile 
manager 2 06 in the context of any user or group. Only the administrator 
5 can change from his/her context to administer clients (users) and groups. 
The server will not allow a user without administrative authority to 
switch context, when a request comes into the server, it will query the 
authenticated ID of the user trying to access this function. If the user 
does not possess administrative authority, (i.e., is not a member of the 
10 AllUsers. Administrator group), the Profile Manager Servlet 214 will 
reject the request. 

Profile manager 206 invokes other applets, such as appletl (20B) , as 
shown in Fig. 2. In this example, appletl might be the administrative 

15 applet for configuring preferences related to user desktops. Or appletl 

could be a configuration utility related to an end user applet, such as 
editors, word processors, databases, etc. It is preferred, but not 
required, that configuration applets such as 208 exist as modules separate 
from their corresponding user applets. In the context of Fig. 2, Appletl 

20 is typically a configuration applet for a user applet; the administrator 

rur.£ the configuration applet appletl under a group content to set group 
prp.Tioo.ence and p*?.. mission defaults, or in * user ccnte::l customize user 

conficu,.c.: ,,:s for an .individual. By implement ii.-v appletl as a 
mouo:-: separate from its user applet, performance is e :} iced, since the 

25 configuration appletl will likely be small compared to the user applet. 

Also, separate configuration applets allow the administrator to control 
the end users ability to configure the user applet. 

Traditional stand-alone computers store user applet configuration 
30 information locally in association with its the user applet. Traditional 

stand-alone Java based computers store user applet configuration 
information using the format provided by the j ava . util . Properties class. 
Both arrangements require that the user applet specify the name of a local 
file in which to store configuration information related to the user 
55 applet. In other words, a relationship is required between the computer 

and the user applet loaded on it. Profile management as described herein 
provides the familiar capabilities of a real j ava . util . Properties object 
plus additional facilities supporting user- roaming capabilities and 
seamless pluggability into a powerful administrative framework (the 
40 Profiie Manager) . 

Prof ileManagementProperties P 210 is a properties object for appletl 
and provides an API between Appletl and the server that allows the server 
to determine where to store configuration information for appletl in the 
45 context of users and groups. The Prof i leManaoementPropert ies object class 



BNSDOCID: <WO 9957663A1J_- 



NVO 99/57 8«3 



12 



PCT/CB98/43866 



provides all of the functionality of the java. util. property .^ass with 
the further ability to provide create, save. enc retrieve the 
configuration information for software fro* permanent storage. storing 
such anfor.at.on in a central location makes management of user and orlp 
configurations possible. group 

When a user is in the role of administrator. Prof ileManagementProperties 
210 allows the administrator to configure the user applet correspond to 
con igurataon appletl, or to confine appletl if appletl is an end user 
applet, and store the configuration information in the proper plac! L 
server in -the proper context. This allows the establishment of a 
relationship between the user applet and the user, rather than between 
user applet and computer as in traditional systems. 
ProfileManagementProperties 210 is an extension of the 

java. util. Properties class. The extension allows the key/value pairs of 
preference information of a Properties object to be associated with a key 
as opposed to a stream, as with java .util . Properties . This, in turn 
allows application developers to use the key to specify a unique location 
relate to a context for preference information, rather than a file naZ 
ana path. Prof ileManagementProperties 210 determines the key 

"iirp-c";^' 7: 96nerati0n ° f the ^ i£ more in connection 

..ith F.g. s „ and S. By modelling Prof ileManagementProperties 210 after 

save.ctz.: Properties .lass, the cyntam can take advance r- 
Reference ,:,oeritance through recur vi-e class default evaluation. Thus 
tnas extended class provides a "group default" capability by accumulating 
presences starting at a current context, as discussed with respect to 
Fig. J , anc traversing up the contextual hierarchy for defaults. 

Server 202 includes a database 212 that stores user data and g^oup 
data, such as user and group preferences and user applet access 
Permissions Webserver 218 represents a typical web server with support 
for oava applets. Profile Manager servlet 214 maps user and group 
ioentifications to preference data, it also maintains an access control 
last to manage user access to applications on the server. 

^n rio U T "« a 9r ° UP Prefer£nCe£ »" " • tr.ee hierarchy. es shown 

l.Z " ^\ £y£tem eUt ° mS tic8l3y belon * *> ^ P croup 

Al Users. All users belong to the AllUsers group.- this group contains the 
oefault preferences for some or all user applets on the server. In rig 
3. it i. assumed that the server contains at least three user applets 
identified as App3. App4 5n d App5 . As indicated in the AllUsers croup 
the oefault background ,boJ for App3 is BG = blue. Other illustrative' 
pre erences labelled as x. y and 2 £re shown to have the default values of 
a. 2 and 3 respectively. The terms x. y and 2 are intended to represent 
any oesareo preference and the values 1. 2 .and 3 are arbitrary and us"d 
-rely to illustrate the point. The x preference might for example £ the 
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screen font for the desktop; the value x =• 1 might call for a default font 
of Times -Roman. Similarly, the default preferences for >App4 for all users 
are BG = grey, x = 2, y = 2 and 2=2.. 

5 The default values in the AllUsers group can be modified in any 

desired way for other contexts, such as for other user groups and 
individual users. By way of example, in addition to the context of 
AllUsers in Fig. 3, four other groups (GroupX, GroupY, GroupYl and 
GroupY2) are shown. Additionally, two individuals Userl and UserN are 

10 shown. Users can be members of more than one group. In Fig. 3, Userl is 

a member of AllUsers, GroupX and GroupYl; UsenN is a member of AllUsers 
and GroupY2. If a user is a member of more than one group (another group 
in addition to AllUsers) , then the groups are prioritized for the purpose 
of selecting the preferences for a given applet for that user. The 

15 administrator configures the group priorities for a user. Group priority 

is illustrated in Fig. 4 . * In Fig. 4, Userl has GroupX (identified by the 
fully qualified name of AllUsers . GroupX for his or her highest priority 
group. Userl 's next highest priority group is GroupYl 

(AllUsers .GroupY. GroupYl ) . Userl's lowest priority group is the AllUsers 
20 group. when a. user, say Userl, requests to run an applet say App3 , the 

preferences are coalesced frc:x\ the tree of Fig. 3 according to the group 
jr croups to wh.'.u.i the user longs ar.u \ ^ user applet Ls configure a on 
v.zeT desktop accordingly. 

25 The first step in coalescing preferences for any context is to get the 

defaults. The defaults for a user, if there are any, is the coalesced 
set of preferences for the applet from the highest priority group from 
which preference information for the applet can be obtained. The defaults 
for a group, if there are any, is the coalesced set of preferences for the 

30 applet from the groups parent (i.e., The AllUsers group is the parent of 

AllUsers .GroupX) . If a group has no parent (i.e., the top level AllUsers 
group) , there are no defaults for that group. To coalesce the preferences 
for an applet at a context, the preferences for the applet explicitly 
stored at the context, overwrite the default preferences for the applet 

35 for the context. Thus, to coalesce preferences into the default set for 

an applet in a group context, recursive calls are made from each group 
node up to the AllUsers group requesting each parents set of preferences 
for the applet. Please refer to figure 3 to illustrate the following 
example. For example, if the context is Allusers .GroupY .GroupYl , a call is 

4 0 made to the parent of GroupYl, which is GroupY, requesting its default 

preferences for the applet. GroupYl mekes a recursive call to its parent, 
which is AllUsers. AllUsers has no parent, so AllUsers returns it set of 
preferences for the applet to the call from GroupY. This set of 
preferences is modified by the preferences stored in GroupY for the 

45 applet, if any. This is now the default set of preferences for the applet 
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10 



15 



20 



25 



40 



for the context of GroupYl . This set of default preferences is returned 

are TI 1 IV * ^ «" « -Ground 

are modrfaed by the preferences at GroupYl for the applet, if any to 

become the actual set of preferences to be used in this instance.' The set 
of preferences for the context of a user is built in -the same way, except 
llll 1 t 9h T Pri ° rity Sr ° UP WMCh information caT" 

which the Tf T " ^ firSt 6Stablish the context from 

whrch the defaults will be obtained. Then the recursive procedure 
cescribed above is used to build the actual set of prefaces for the 
user and the applet requested by the user. 

an, J 1 ^ 110 " 1119 SXamPleS illUEtrate the ab <™e Preference coalescence 
and should be read in conjunction with Fig. 3. 

Example 1: An administrator runs a configuration applet for App3 to 
set preferences for the group Allusers .Groupx. 



To set the preferences for App3 in the context of Allusers .Groupx 
the present set of preferences must be determined. Al HJsers Groupx 
requests defaults for its parent Allusers. Since Allusers is the top 

..eve! gronp. it returns its preferences for App3 to .Groupx. These are the 
° efaiUC ^ •*-•" ^ ^e ..ontext cf Grvupx. si.ce Groupx ^ 

no Pr-=f--r-.rMS for .:. . the default set from Allusers is the real set • ■- 

!^, f , er£nC " 60 ^ USed ' In thlS exam P le ' the « preferences from the 
25 Allusers group are : BG=Blue , x=l, y= 2 , z=3 . The administrator can now 

-odify use the configuration applet to modify the coalesced preferences in 
any desired manner. 

30 Example 2: Userl requests execution of com. ibm. App3 . Preferences 

30 must be coalesced for com.ibm.App3 in the context of Userl . 

Fig. 4 shows that the highest priority group for Userl is 
Allusers. Groupx; this branch of the croup hierarchy will be checked first 
: or preference information pertaining to Ap P 3 . From here on, the example 
is essentially the same as example j above, except that the coalesced ««t 
°' P referen "s ^ «sed to configure App3 on the user's workstation The 
preferences for Ap P 3 for User. are , BG=Green, x=l, y= 2 . 2 =3 since the 



Rr . rroo „ _ • ^ * y=^. 2=j since the 

BG-Green preference stored in the Userl's context for App3 over rides the 
default BG=Blue preference obtained from the AllUsers .-Group* branch of the 
preference tree. 

Example 3: Coalescing preferences for com. ibm . A PP 6 in the context of 



Userl . 
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This example illustrates the situation of the highest priority group 
containing no coalesced preferences for the context of Userl. Again, the 
highest priority group for Userl is GroupX. This group and its parent 
AllUsers contain no preferences for App6 . Therefore, the next highest 
priority group is searched. The next highest priority group for Userl is 
GroupYl. A set of preferences can be obtained from this group for App6 . • 
The coalescence of preferences proceeds as described in example 1. 
Recursive calls are made from GroupYl up the tree to the root AllUsers 
group and the preference sets are returned back down the recursive calls 
and modified along the way to form the default set. The default set is 
then modified with the preferences stored in GroupYl to form the 
coalesced set of preferences that apply to this context. Stated briefly, 
Allusers returns a null set of preferences, since it has no preferences 
for App6. GroupY modifies this null set with the values a=l and b=2 and 
returns this set to GroupYl as the default set. GroupYl modifies the 
default set with a =33. This set is returned to the Userl context for use 
as its default set. Since there are no preferences for App6 stored at the 
userl context, the defaults obtained from the GroupYl branch of the 
preference tree represent the fully coalesced set of preferences for App6 . 
The real set of preferences thus becomes a=33 # b=2 for this context. 

The above 3 examples described the gathering of preference- .^i 
response to a IcadO for a particular piece of software. Whe^ ^^-'ence 
information is saved for a piece of software, any preferences the*., nave 
been explicitly written at the Context being saved to will be written to 
the data store (212) at the location specified by the combination of the 
Context the software is being run in and the key for the software whose 
preferences are being stored. 

Permissions operate similarly: a new group has access to all the 
applet names permitted by the group itself as well as to all applets 
permitted by its supergroups. However, just as Java allows the programmer 
to override a superclass method, Profile Management allows the System 
Administrator the ability to override an inherited permission. This is 
called overriding a permission . 

As with Java's form of inheritance. Profile Management's form of 
preferences and permissions inheritance is called single inheritance. 
Single inheritance means that each Profile Management group can have only 
one supergroup (although any given supergroup can have multiple 
subgroups) . 

Profile Management users (leaf nodes) may require membership in 
multiple groups, so a facility is required^ to limit preference inheritance 
to a single hierarchical group to minimize the chance of corrupt 
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9Ur8 7 ° US t0 the Production of incompatible variable subset, 
-troouced by cross .roup branch coalescing. By allowing a user" g^up 
membershaps to oe prioritise, profile management can tollov) a searlT 
oroer when looking for preferences relate * • ° W * searich 

c ences related to a particular applet in 

S other words, st.rtip, with the 9 ro»p „ lth the hlshest priori ". ^. " 

tn nor™** / ^ controls access by programming the web server 

to permit / deny access to applets. The web server enforces the acceJ 
control. The profile manager servlet 1 thC acces s 

it; et 1S also protected by the Kebe-n,.- 

15 requiring user ID's and pas^woroc v. „ webserver 

pas^worcs to be passed to the webserver for 
authentication purposes, it is R t ? r>«^ v. * «"ver tor 

stancard browser functionality to promDt 
for user passwords as required. prompt 

20 . 5 Sh ° WS ° f Fis " 2 in more ^tail. Configuration 

20 applet Applet! is invoked bv th c ■ iguration 

anvoxeo by the ooministrator within the profile 

management framework. Appletl ma- imolem^nt f v n a ™i ■ 
irt— £-c- "mi 5 « • P1 -"' Cnt the application program 

T • ?I) 5i5 EOr ; -formation abn-,t its oner h ■:- ioMl 

nrofil " " thiS C ° nteXt ' etC ' ) " int& — with Tn the 

-s- profile management framework, but this !«, nnf » 

. tnis 1S n °t a requirement for a 

configuration applet, in any event, the designer of appletl need only 
uncerstanc the basic API methods: enablePersistence (, . load () . L save (, 
in add-on to the basic methods of a ja va.util .Properties ob ecfusea to 

neL i " V Pr ° Vide£ ""° and ^Context.) methods. Apple" 

the se ° nJy h re91£ter Pr0fil — agementProperties class and call 

" SPPr ° Priate - lo.dC, method can be called to retrieve 

the present state of preference* f nr trieve 
„^ ^ pxererences for the user applet beino conf i-gured in 

the context of a user or group selected bv tho • • ™«*«uJEee m 

- c ... • - ^ -ejected by the administrator The 

aaministrator can then nn^i'v , 

cnen modify „ ne preferences as desired and store t-v^m 
using the configuration save f^Hrr-v. . store tnem 

„ CC c *v -Jnctionality provided by the applet •< which 

uses the save,) method of its Prof ileKanagementProperties -object 
Similarly, if appletl needs the list of user applets author^ for access 
by a user it can use the listO method to obtain the list from the 

LmTof th 9etCOnteXt ° meth ° 6 «» b. used by the applet to" ^Ly the 
name of the context that it is running in or even to ensure that it Ly 
runs m a certain context (i.e., if an eppl£t wanted tQ configure ^ M * 



45 



serv.ee o„ the server „ si „ 9 the „ port awt , jt *J£ 

to be run et the AllUsers context cinrc -v*« seAt 

^.uutex. since the configuration beino Pxnnrf C ^ 
» server spe= ifi c 6S oppose, to user spec 1£ic . P or .^Tl ™ 
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the profile manacement framework, all that is required is for the applet 
to register with Prof ileManagement Properties 410 and implement the 
Prof ileManagementProperties class, an extension of the 
java.util .Properties class. 

5 

The profile manager 506 also provides a context change API 516 for • 
configuration applets. Appletl may implement a context change event 
listener 512. The API 516 and the event listener 512 allows the 
administrator to change contexts (user or group) while running the 

10 configuration applet, without having to stop and restart it. For example, 

when configuring applet user preferences, the administrator will likely 
change contexts many times during the configuration. If the configuration 
applet is registered as a listener to such events, profile manager 506 
will notify it of a context change via API 516. This allows appletl to 

15 refresh its preferences from the server for each new context. without the 

event listener API, appletl would have to be terminated by the 
administrator and restarted after a new context has been selected to 
reference the existing preference information for the new context and 
avoid being stopped and restarted by the Profile Management applet. To 

20 register, appletl calls a method on its properties object 

Prof ileManagement Proper siies 510 i.e. a0.t:;ContextChang£Listencr (API 516) 
to register \ o-* 1 f . Wh er>. t h -i admin i s tr j -;cr sets r. r. :2w con text, profile 
manager 5 06 performs a set context call (API 516) to object 510, which in 
response calls the reload method (API 516) on evc-r.i listener 512. Event 

25 listener 512 now performs a load properties call to its properties object 

510 to get the new preference data from the server for the new context, 
and causes appletl to updates it GUI and internal variables to reflect the 
new preference information. 

3 0 The above functionality avoids the possibility of a network 

administrator reading data from one context, changing context, and 
accidentally overwriting with a save O when intending to loadO before 
making configuration changes in the new context. 

25 Applets that do not register as iisteners will be stopped, 

destroyed, reloedec, and restarted by the profile manager applet when the 
administrator forces a context change. 

The profile management also provides a "properties export " service 

4 0 to allow the easy retrofitting of existing hardware and software into this 

profile management environment. The properties export service allows 
profile manager 514 to support user workstations (the physical hardware) 
as well as users, groups, and user applications. Since existing 
workstations do not know about Prof i 1 eManagementProperties 510, the export 
45 service allows workstation vendors to create workstation- oonf iguration 
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applets that specifier ^ 

when the vendor ap p e ^ " ** OJ1 the "~ 

causes an J a 1 1 ? T information. The export tag 
object, to be created LHT ClSSS ^ ^ 520 

specify that wor* , 2 " " ^ ^ <» 

proprietary f„. £ca ^~ ^"T^ af ° attl « ^ "ved in whatever 
workstation bein g conf^^f ^ quired by the - 

Assume that applet 1 ac 
for an existinc te^nal that L °° n£lflUr ? ta « £p » let Provided- by a vendor 

management syst'em v«L .! ' ' ^ ^ PP#MBt Pr ° file 

" iJi e vendor also sunni i oc o^-^^*. 

administrator can confix . " XP ° rt * 9ent 520 • Al- 

corn igure the terminal for ooeration 
running profile manager 506 »t the operation in this system by 

configured, runs the vendor', V t0 bein * 

the applet. ^J^^^^^^ ~ ««9«. 

information that is tra^^T^ COnf igUratio »< P«t of the 

-ntifies the t^=^^~^ «~ 

StV^iizir:::: of the ~ ^^rr. 

servlet 51, detect thi frl o °" Pr ° file 

specifies ,eed for the e^" Zl ~ f «— « that 

tag in the of a ksy CJlue^al- ' ^^^^ Gp€Cifies the expert 



,xx XE xPO RT _ AGENTXXXX= , fully gu£lif name ^ ^ ^ 

is caiL 6 zz: Toiii:z: ttcontext context - ^ 

522 on the server Trol lL ZTl 7^ '° ^ ° r — 

file or files are io'tifie bv £ " i » f0n ' Ml «- *» ^cific 

came with the propertied nforL T*" "•° tl "~ of **• terminal that 

later boots up i " " ™ aPPl *"- the 

^/ uses ats unioue identifier- t-r> 

prefers „a th. I"e "* " 

change by th. M S I , " " y B ™ £e "»«= ">« «,ht be 

xupe-.ies object for appiet2 with context em = i ,v 

anc generates the unique Key for identifying, the prefer e" e Z 

storage location on the server, ££ described abovl -ela"I" "T" 

aaminjstr-ator. ^wv^ relative to the 
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Fig. 7 shows the situation of a user bringing up his or her desktop. 
The user on the client (700) points his or her web browser at the URL of 
the desktop applet on the server and at step 704 sends a message 
http: //server/Desktop. html) . Since Desktop.html is a file that the server 
protects, a challenge is sent back to the web browser on the client at 
706. The web browser on the client responds by prompting the user for a 
user ID and password. The client then sends the user ID and password 
information to the server at 708. The user ID and password are shown in 
bold at 708 of Fig. 3 to illustrate that this information is passed by the 
web browser itself. This type of nomenclature is used in other places to 
illustrate the same thing. Since, presumably, the user has permission to 
run the desktop applet, the request will be honoured. 

There are a series of interactions between the client and the server 
(not shown) where the code for the desktop applet is loaded to the client 
from the server. The desktop object is created and begins to execute at 
712. The desktop object needs its preference information (i.e., 
configuration information) so it can tailor the desktop for the end user 
who is invoking it. To this end, as part of the desktop object's 
initialization process, the desktop creates a Prof ileManagementProper ties 
object P at 714, which is used to lead, cc-t, cache, set, arid s^vc a 
c ohv of the war's pr e f e r sn c z i n f or ma t i or, " rem the h v v.. r^r for t h e "jsktop 
applet. The desktop object then performs an API c:. • 

P. enablePersistence (desktopObj ect (applet)) at 716, which, at step 1) of 
716, initializes the Prof ileManagementPropert ies object P with the URL. of 
the profile manager serviet 214. This URL is derived from the URL of the 
desktop applet that was loaded from the server previously. The 
Prof ileNanagementProperties object P sends a request 718 to the profile 
manager serviet 214 to get the context for the user running the desktop 
applet. In this case, the context consists of two components, a context 
name which is the ID of the user, and a context type which in this case is 
User. The profile manager serviet gets the ID of the user from the request 
718 and returns the user context at 719. At step 2 of 716, the 
Prof il eManagementProperties object P is initialized with the context of 
the user running the desktop. At step 3 of 716, the 

Prof ileManacementProperties object P generates e unique key for the 
desktop software by asking the Java desktop object P for its fully 
qualified class name. All Java objects know their class name. This unique 
key is combined with the user's context information to provide a parameter 
that specifies a unique location in the database 212 for storing the user 
specific preference information for the desktop applet. Any desired 
method can be used for mapping the string consisting of the fully 
qualified class name and the user context information into the data store 
location . Next, a request 720 is sent to the profile manager serviet 
214 to get the preference information, tailored for the user, for the 
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Desktop applet. The context and key are passed as z>*rr ^ ^ 

ll^TiZ the reQue£ted — inf ™ ™ 720 

servlet 214 responcs with the requested preference information at 722 
which is cached in the Prof ileManagementProperties object I Tot 

prefer^ 1 ^ 9 °° " 8 ' " 8 °° ^ DeSkt ° P ««~* «a<is ifs 

preference information out of its Prof ileManagementProperties object P 
and begins to update the desktop accordingly (i.e.. it might set "he 
screen colour to blue, get information about the position „f • 
The desktop object calls a method on its Prof nlZ „ o^™ ' ' 
ob 3 ect P to get a list of the software to which the user has S T 
permission. The Prof ileManagment Properties object P requests the 
information at 802 from the profile manaoer servlet 214 wh,> h 

1- whach the user has access, the information includes a uw 

:h h :t a rr:: Q :jL L ' f the r- of an icon for the ~ - ' 

and to load - " ° " repre£ent th * -PPl*t on the desktop 

and to load ano aaunch it,, and other optional material which is „ ot 
relevant to the invention. This information is stored in the 

It° 0 eMana9mentPr ° PertieS ° bjeCt r€tUrned t0 the — *«* object. 

tor "' ;"V 6S " tG - °" ;jeCt U-a ° apPlet to b«i M a folder 

for e applets an, t, generate , window d,,, A , ylng the i,,,s and the ,,= r 
friendly name for each applet to which the user has access 
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Assume that in a previous run of the desktop by the user th* .™ 
dragged and dropped the icons for some of the sofLare dlsp layed Tn ITJ 
foicer that was just described. it is possible that at this time the user 

"oi r:: eccess to the appiets ^ - — tiz 

Part of th ae£KtOP ' HOW6Ver ' th££e deEkt ° P wou-ld be a 

would st.Jl PrEferenCeS th " We " —a during the last run and 

would stall be displayed on the desktop . To avoid this situation< the 

oesktop examines its preferences from it's Prof ileManagment Proper! es 

wtno 6 :: ii: check for eppiets thet are cm£i *™* - ~ 

" I ce" P C 1£ e eenerated t0 eli ««"•*. to which the user has 

" • . F ! S - 6 S£SUme£ that there one applet outsioe of -the 

applet window the: -is aeneratPr t/ *v^„ 

outqiri6 „, „. . oeneratec. if tnere were more than one such applet 

cutsaoe of the appaet window, the following procedure would be looped for 
each such applet. At step 810 the desktop checks each of these l^plet 
appearing outside of the applet window against the lis, of applets lZ 
he server to which the user has access, xf -the applet appears -in tne 
list the icon for the applet is placed on the oesktop at 810 in the same 
Position as before. Xf the user no longer has access to the ap P le ttL 

rom h e S orT- e<3 deSkt ° P ' £ « -«P 814 anc remold 

s Irt o : ^ M£n69mentPrOP " rtie£ ° b5eit ^ U any •« removed 

as part of tnis process, the desktop tells the Prof ileManagment Properties 
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object P to save the preferences at step 816. The 
Prof ileManagmentProperties object P sends a request 818 'with the 
preference, key, and context information to the profile manager servlet 
214 to save the new preferences information in the Database 212. The 
5 server sends a response 820 to the Prof ileManagmentProperties object P 
informing the Prof ileManagmentProperties object P that the request was 
successfully completed. 

Fig. 9 illustrates the situation of an administrator running a 

10 configuration applet to configure preferences for an applet for other 

users or groups of users. It is understood that the principles discussed 
here also apply generally to the configuration of terminals or groups of 
terminals. The administrator on the client 9 00 points his or her web 
browser to the URL of the profile manager applet 214 on the server, which 

15 is to be run. The URL is sent to the server at 904. Since 

ProfileManager.html is a file that the server protects, a challenge 906 is 
sent back to the web browser on the client. Tjie web browser responds by 
prompting . the administrator for a user ID and password. The request to get 
ProfileManager.html is then repeated at 908 to the server with the user ID 

20 and password information included in the message. Since presumably the 

administrator has permission to run the profile manager, the request is 
honoured and a profile manrjr-i" applet is downloaded cu che administrators 
terminal at 910. There are a series of interactions between the cliant 
and the server (not shown) where the code for the profile manager applet 

25 is loaded to the client from the server. The profile manager object is 

created and begins to execute at step 912. 

A Prof ileManaaementProperties_nonContextFloating is used by the 
profile manager instead of a normal Prof ileManacementProperties object.. 
30 It has the same behaviour as a Prof ileManagementProperties object with one 

exception: when preferences are loaded and saved, they are loaded and 
saved to and from the context of the administrator who is running the 
profile manager, as opposed to loading and saving to and from the context 
(i.e., user or user group) for which the administrator is configuring. 

35 

The profile manager object needs its preference information (i.e., 
configuration information) so it can tailor the profile manager for the 
administrator is invoking it. To this end, as part of the profile manager 
object's initialization process, the profile manager creates a 
40 Prof ileManagementProperties_nonContextFioating object P_NCF at step 914, 

which is used to load, get, cache, set, and save a copy of the 
administrator's preference information from the server for the profile 
manager applet. The profile manager object then calls 

P__NCF . enable Persistence (prof ileManagerOb j ect (applet)), which in step 1 of 
45 916 initializes the Prof ileKanagementProperties_nonContextFloating object 
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p_ncf with the url of the profile manager servlet 214. This URL is derived 
from the URL of the profile manager applet. The 

Prof ileManagementProperties_nonContextFioating object P_NCF sends a 
request 918 to the profile manager servlet 214 to get the context name 
5 (ID) of the administrator ana the context type (USER) . The profile manager 

servlet gets the ID of the administrator from the request "(918). The web. 
browser passes the administrator ID and password in the message along with 
the information sent by the Prof ileManagementProperties_nonContextFloating 
object P_NCF. The ProfileManagementProperties_nonContextFloating object 
10 P_NCF is initialized with the context of the administrator running the 

applet at step 2 of 916. At step 3 of 916, the 

ProfileManagementProperties_nonContextFloating object P_NCF generates a 
unique key for the profile manager applet by asking the Java 
profileManagerObject object (passed as a parameter in the 
15 enabiePersistence call) for its fully qualified class name (i.e., 

profileManagerObject.getClasst) .getNameO) . This unique key. combined with 
the administrator's context information, is mapped to specify a unique 
location in the database 212 for the administrator's specific preference 
information for the profile manager applet. 

20 

A request (S22) is sent to the profile jnanc-ger servlet 214 t-c get 
the preference information tailor.*,? for the prcrile manager applet as 
conf - ; .tr • : for the af.~;i:aistrator . The reque-r ($22) includes the 
appropriate context name and type and key information to identify the 
25 appropriate preference information. The profile manager servlet 214 

responds with the requested preference information (924). which is cached 
in the Prof ileManagementProperties_nonContextFloating object P_NCF. The 
profile manager reads its preference information out of the 
Prof ileManagementProperties_nonContextFloating and updates itself 
accordingly (i.e., sets its background colour to blue for example). 

Operation continues at Fig. 10. The profile manager requests the 
information about existing users, user groups, and software from the 
profile manager servlet 214 and builds the tree in the left panel of the 
profile managers configuration window at 10C2. See Figs. 13 through 24 
for examples of the administrator's left panel. At this point 1004, the 
administrator selects a desired context for configuring by clicking on e 
user or group from the left panel tree. The profile manager sets the 
context for Prof ileManagementProperties objects by calling 
P_NCF.setContext (selected context). See Fig. 13 for a selected context of 
'User Groups', which refers to the group of all system users, or to Fig. 
18, where a group context of 'Development' is selected, or to Fig. 21 
where a user context 'colleend- is selected. Next, at step 1006. the 
administrator selects an applet ...tP..be configured from a list of all the 
applets on the server. See Fig. 17 for an example of selecting an applet. 



30 



40 



BNSOOCID: < WO PSST663A \J_ > 



WO 99/57863 PCT/GB98/03866 

23 

At step 1006, the administrator then clicks a Run/Customize button to run 
the applet selected for configuration. This applet might be a separate 
configuration applet for an end user applet, or it might be the end user 
applet itself. The selected applet is requested and loaded from the 
5 Server at 1009 and 1011. At step 1010, the configuration applet object is 

created and begins to execute and to generate its 
Prof ileManagementProperties object P. 

If it is assumed that the applet is a separate configuration applet 
10 for an end user applet, then at step 1012, the applet calls 

p. enablePersistence (conf igAppletObj ect , 

f ullyQualif iedClassNameOf AppletBeingConf igured) . On the other hand, if 
the applet is a user applet, rather than a separate configuration applet, 
the call would be p. enablePersistence (endUserAppletObject) since it wants 
15 to configure its own preference information as opposed to the preference 

information for another applet. The current Context is already known by 
the Prof ileManagementProperties object P since it was previously set by 
the administrator vis the administrator's 

Prof ileManagementProperties_nonContextFloating object PM_NCF. The location 
20 of the profile manager servlet 214 was previously generated when 

enablePersistence was called on the Profile Managers 

Fr r.f ileManagement Proper ties__ronCon text Flo?/ 1 ing object l-w.NCF. In tvr r case 
c s configuration applet, the unique key for the apu?'Ot does noi: need to 
be generated because it is passed by the configuration applet to the 
25 Frof ileManagementProperties object P in the enablePersistence call. 

At step 1014, the configuration applet registers itself with its 
Prof ileManagementProperties object P as a context change listener. As 
discussed earlier, this allows the applet's Prof ileManagentPropert ies 
30 object P to notify the applet if the administrator makes a context change 

so that the applet can load the preference information for the new context 
and update its Graphical User Interface to reflect the new configuration 
information, without requiring that the applet be terminated and 
relaunched in the new context. 

35 

Operation continues at Fa c . 11. At step 1104, the configuration 
applet tells the Prof ileManagementProperties object P to load the 
preferences from the current context for the applet being configured. A 
request 1105 is sent to the profile manager servlet 214 to get the 

40 preference information, tailored for the context previously selected by 

the administrator, for the applet being configured. The request 1105 
includes the appropriate context name <the context the administrator has 
selected) and the context type (USER, USER_GROUP, or ALL_USERS_GROUP as 
appropriate) and key inf ormation to specify the location of the 

45 appropriate preference information. The profile manager servlet 214 
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responds with the requested preference information at 1106, whioh is 
cached in the Prof i leManagemen t Proper ties object P. The configuration 
applet gets preferences from the Prof ileManagement Properties object P and 
updates its Graphical User Interface accordingly. 

The administrator configures the applet at 1107 and saves the 
modified preferences., for example by clicking a SAVE button provided by 
the applet. As a result of this operation, the configuration applet cal Is 
the savej) method on its Prof ileManagementProperties object p. The 
Prof ileManagement Properties object P sends the preferences .and the unique 
key for the applet being configured and the information specifying the 
current context to the profile manager servlet 214. The profile manager 
servlet stores the preference information in the database 212 in the 
location specified by the Context and the key. 

Step 1108 is an example of the administrator now changing -context, 
while the configuration applet is still running. The administrator 
selects a new context by clicking on a user or user -group (see Fig. 18 for 
examples of new contexts in the administrators lef t screen panel) . As a 
result of the context change, profile manager 506 sends a set context 
message to Prof i leMangementProperties object F (510) by calling 
P_^CF. -et^oi.cext {seie-...ud K'HW cent--.!.), which in turn caus-as object P to 
notify event listener :\.i2 of tfc* —text change via the reload properties 
API 515. This occurs at step ill:., step 1112, the event listener 512 

performs a loadO call to retrieve the preferences for the new context and 
the object P is updated with the new preferences at step 1118. The 
administrator can now proceed to modify the new preferences for the new 
context, if desired, and to save them if required, and then to proceed on 
with a new context change if necessary as described above. 

The remaining figures 12 through 24 show actual screen snapshots of 
an administrator's workstation while running portions of the profile 
manager 206. 

The main configuration window 1200 is shown in Fi-gure 12. The tree 
view panel 1202 on the left of the window depicts profile management 1204 
as one of several services available on the server. When this item 1204 is 
selected as shown in Fig. 12, the right panel 1205 of -the main window 
displays a welcome message for the profile management service. Expand and 
contract icons such as 1208 are used to control the appearance of 
sub- items under , an item in the left panel, if any exist. The ' + ' in 12'08 
is called an 'expand icon' and indicates that there -are sub- items beneath 
'Profile management'. The administrator can display these sub-items by 
clicking on the expand icon 1208, which will then become a 'contract icon' 
('-'). 
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Fig. 13 illustrates an expansion of the Profile management item 120e 
in Fig. 12, which results in the display of three default sub- items in 
Fig. 13 - 'Applets' 1300, 'User Groups' 1302 and 'Users' 1304 . Expansion 
icons indicate that these items can also be expanded. 'Applets' 1300 
5 allows the administrator to define the user applets available on server 
202, 'User groups' 1302 allows the administrator to create and populate 
the user group tree of Fig. 3 and to set group preferences. 'Users' 13 04 
allows the administrator to create new users and to set their preferences 
or to change preferences for existing users. In the example of Fig. 13 

10 'Applets' 1300 is selected. When this item is selected, panel 1305 on the 

right of the window displays a list 1306 of user applets that have already 
been defined to the system. Attributes of the application that is 
selected in 1306 are shown at 1308. The administrator defines a new 
applet by selecting <NEW> in 1306 and entering the name and location 

15 information requested in 1308. An existing applet 'Database Explorer* is 

shown selected in 1306. At 1308, the 'Applet name' field displays t h is 
applet name. The ' URL' (Universal Resource Locator) field displays the 
Intranet or Internet web address of this applet on server 202. The field 
'Complete path of html file' displays the directory path and file name of 

20 the applet in the disk directory structure of server 202. The field 

'Fully Qualified class name' displays the fully qualified class name of 
tha applet. T>-~ field ' Ice- URL' display* a wet) accrr ..s of the xtt-.: _■•= file 
used to generate an icon for the applet on a users desktop. The • raining 
fields are fcr optional information that may be required by the software 

25 upon invocation. A command button 1310, 'Import Applet List from File', 

allows the administrator to append definitions of applets to the existing 
list 1306 from an existing text file. when button 1310 is clicked, the 
window shown in Fig. 14 pops -up and allows the administrator to enter the 
path and file name of the text file containing the applet definitions to 

30 be appended. To save all pending changes, the administrator clicks on 
File 1312 and then Save (not shown) . 

in the left panel, the User Groups item 13 02 corresponds to the 
AllUsers group of Fig. 3 (' User -Groups ' and 'AllUsers' are used 

35 interchangeably herein). Fig. 15 shows the right panel of the 

administrators station when the 'User Groups' item 1302 is selected. In 
Fig. 15, a notebook panel is displayed on the right that contains three 
tabs - a Members tab 1514, a Subgroups tab 1516 and an Applet Permissions 
tab 1518. The Members tab is selected in Fig. 15. The Members panel 

40 contains a list 1520 of the log-on identifications of all members that 
have been defined to the system. To create a new user (who will 
automatically gain membership into the presently selected group context - 
'User Group'), the administrator selects <NEW> from the list 1520, enters 
the appropriate information in the entry fields 1522 to the right of the 

45 list, and then clicks on the Create button 1522. when an existing member 
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is selected from the list l^n ^ 

user are displayed at 2 1 r "™*»*Y -ved for that 
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the File button in the top .enu bar and then save (not shown). 

30 Pe r.iss": ns \\r:r: E th i/: e t c :: nei : hat is dispiayed ^ 

applets that have n en L'ned to'th ^ ° f 811 

- ae.med to tne system and the permission stai-,^ 

(permit or oeny access) that is assigned to each applet for £ 1 
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35 the status depicted £ c exclamataon .point indicates tha* 
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40 the system. For examp t " UM " te ^ defined to 
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button 1732- Furthermore, regardless of an applet's permission status for 
the selected context, an administrator can select an applet from 1720 and 
click the 'Run/Customize' button 1734 to execute the user applet under the 
selected context. The panel region previously showing the notebook for 
5 the current context then becomes occupied by the executing user applet. 
If the user applet happens to be a configuration applet for other 
software, the administrator can then save software preferences (through 
the configuration applets unique facilities provided for this function) 
which will then be saved as the software's default preferences for the 
10 selected context. If the applet is an end user applet, the functions are 

the same, except the end user applet loads and saves it own preferences 
rather than preferences for a separate piece of software. 

Fig. 18 shows the complete expansion of the administrators left 

15 panel subgroup tree beneath 'User Groups' . Immediately beneath 'User 

Groups', there are two subgroups 'Administrators', a default subgroup that 
cannot be removed, and 'IBM', a subgroup defined by the administrator. 
The ' IBM' subgroup has also been expanded and contains three subgroups 
'Hardware', 'Services' and 'Software'. The 'Software' subgroup has been 

20 expanded and contains at least one subgroup called 'Development' . The 

•"Development' subgroup contains at least one subgroup called MCoD. 
Subgroup ' NCcD' contains ~ number o'<: out-groups, such as Conf.igFw 58, which 
have no children. Also in this example, subgroup 'Development* is 
selected in the expansion • ree. Since 'Development' is not at the top of 

25 the tree hierarchy (the 'All Users' group), the notebook shown in the 

right panel is somewhat different from that of Fig. 15 when 'User Groups' 
was selected, because all users are not automatically a member of 
'Development', as they are of 'User Groups'. The list 1820 displays the 
log- on system IDs of all system members. The status beside each user ID 

30 in list 1820 shows whether the user owns a membership in the 'Development' 

subgroup. A status of 'yes' indicates that the user is a member of the 
'Development' subgroup, 'no' indicates that the user is not a member of 
the 'Development' subgroup, and 'inherited' indicates that the user 
inherits membership within the 'Development' croup by belonging to at 

3 5 least one of Development's subgroups further down the tree. A user's 

membership status for a subgroup is modified by the administrator by 
selecting the user in list 1820 and then clicking on the 'Add to Group' 
button 1836 or 'Remove from group' button 1836. If the administrator 
wishes to create a new system user, or modify or delete an existing 

40 member, the administrator clicks on the 'Create/Modify/Delete Users' 

button button 1840. This action brings up the notebook page shown in 
Fig. IS. The right panel of Fig. 19 is similar to that of Fig. 15 and 
allows the administrator to create a new system user by selecting NEW in 
list 1920 and then clicking the 'Create' button. Similarly, the 

45 administrator can modify or delete an* exa 'sting system user by selecting 
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be denied to colleend by clicking the 'Deny user access button* 2432. The 
administrator can also launch an applet in the context of colleend by 
clicking the ' Run /Customize ' button 243d. When this is done, the applet 
selected in list 2420 is launched in the right panel. The administrator 
5 can then modify any preferences that the applet allows and save the 

preferences in the manner provided by the applet. A typical scenario here 
is for the administrator to launch a configuration applet then to fill in 
a variety of preference fields. However, if a separate configuration is 
not provided for a user applet, the administrator can launch the user 

10 applet in the context of a user and set preferences from the user applet . 

A typical scenario here is for the administrator to select a group or user 
context and then to launch the user applet as described above. The 
administrator can then typically modify preferences from an options menu 
and save them in any manner provided by the user applet. For example, 

15 typically, the user preferences are saved when the options dialogue is 

closed, or the user applet may provide other methods of saving the 
preferences. In any event, since the administrator is running the applet 
in the context of colleend in this example, the preferences set up by the 
administrator through the user applet are saved on the server as if 

20 colleend had entered them directly herself by running the applet. 

Met shown \n < W: figures is a scenario whereby a user can modify 
some preferences pertain io - user appleu. For example, a user 

applet may allow a user to select a window background colour, or fonts 3 

25 font sizes, so that each system user can individualize the applet to some 

extent when the user applet executes on the users desktop. In this case, 
the user modified preferences are saved in the same way as they are when 
the administrator runs the user applet. One difference, however, is that 
the administrator can run user applets to set preferences in group 

30 contexts, whereas users can only affect preferences for their individual 

context . 
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1. in a network system comprising a network interconnecting a server 
and a plurality of user stations, a method of managing desktops on the 
user stations from the server, wherein the server stores a plurality of • 
user applications for downloading to user stations, and further stores 
access permissions for the applications for each.user, *aid method 
comprising steps of: 

receiving at the server a log-on request including a user identifier 
from a user station; 

using the identifier to build a list of applications for which the 
15 user has access permission; 

downloading to the station the list of application, for which- the 
user has access permissions; and 

20 displaying on a portion of the desktop objects -corresponding to each 

application in the list, said objects when selected by the user being 

~ 3 erat>ve to -,-luest a download of the corresponding application ro the- 
u^er static-'.;. 

2. The method of clai* l further comprising steps of: 

using the user identifier to built an icon on the desktop that 
represents a user application specified by the user at an earlier time; 

for each user desktop icon specified by the user at an earlier time 
that corresponds to a user application, checking the access permission for 
the user to the user application; and 

omitting from the desktop any such user- specif ied icon correspondino 
to a user application to which the user does not have access permission. " 

2, in a network system comprising a network interconnect ino a server 
ana a plurality of user stations, an apparatus for managing desktops on 
the user stations from the server, said apparatus comprising: 

_ means f or.receiving at the server a log-on request includino a user 
identifier from a user station;. 

means for usinc the identifier to buiW l a list of -applications for 
wnich the user has access permission; 
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means for downloading to the station the list of applications for 
which the user has access permissions; and 

means for displaying on a portion of the desktop objects 
5 corresponding to each application in the list, said objects when selected 
by the user being operative to request a download of the corresponding 
application to the user station. 

4. A computer program product stored in a computer readable storage 
10 medium for, when run on a computer, carrying out in a network system 
comprising a network interconnecting a server and a plurality of user 
stations, a method of managing desktops on the user stations from the 
server, wherein the server stores a plurality of user applications for 
downloading to user stations, and further stores access permissions fbr 
15 the applications for each user, said method comprising steps of: 

receiving at the server a log-on request including a user identifier 
from a user station; 

20 using the identifier to build a list of applications for which the 

user has access permission; 

dovjnloaciny Ll; -he station the list of applications for which 
user ho s access permissions; and 



25 



displaying on a portion of the desktop objects corresponding to each 
application in the list, said objects when selected by the user being 
operative to request a download of the corresponding application to the 
user station. 
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